前言
上一次在做完 lab2a 即 raft 的 leader 选举之后,一直卡在日志同步这一块(log replication);直到昨晚进行了一下 appendEntries 的优化(prevLog 不匹配时,一下跳过本 term 所有 logEntries),一直困扰的 TestBackup2B 竟然神奇 Passed 的了。跑了两遍还不大信,特地将其改回去,看到果然 Fail 才放心下来,看来是效率太低超时了。
趁着还新鲜,索性今晚就将这一段时间的血泪史记下来吧。
记录下在实现6.824 lab2 raft 的一些想法和经验,聊以备忘。
6.824是MIT的一门分布式课程,我跟的是2018 spring 。在第二个实验中要求简单实现一个分布式一致性协议–raft。
这是一个专为方便教学和工程实现所设计的协议,它将协议拆解为几个相对独立的模块–leader选举,log复制,安全保证。论文里图二基本给出了Raft的所有实现细节,可谓字字珠玑。但也因为太微言大义了,导致有些状态转换分散在不同描述中,假如你真只照着这幅图实现,很容易遗漏些细节。
写程序的时候,规模小,尚不能感觉设计模式的重要性。等规模一上来,需求一迭代,一个应用了恰当设计模式的工程,总能以最小的代价进行最快的迭代。
但是一个奇怪的点是,我总记不住具体的实现所对应的设计模式的名字,但是对他们背后的设计思想,却是念念不忘——依赖于抽象而非具体;对扩展开放,对修改关闭;
编程中有很多有意思的细节,看到了,就记在这里。
|
简化判断一堆数按位或,只要有多于一个数为负,则结果为负。
1 | public void write(byte b[], int off, int len) throws IOException { |
from: FilterOutputStream
上一篇把一些零碎的小类集在一起,凑成一篇。这篇打算对比较长的一个类DataNode
读读。
每个DataNode代表一个数据节点,对应某台机器的一个文件夹,本质上是一定数量的Block的集合,能够和NameNode,client以及其他DataNode进行通信,以对该Block集合进行操作,主要包括client的读和写,其他DataNode block的复制,以及响应NameNode操作,进行删除等操作。
具体实现来说,数据结构上,维持了一个block到byte array的表;执行时,DataNode内部是一个无限循环,不断询问NameNode,报告状态(心跳),执行命令(RPC)。
DataNodeInfo
](/hadoop-source-DFS#datanode-info):总大小,剩余大小,上次更新时间。此外,DataNode还维持着一个Server Socket以处理来自Client或者其他DataNode请求。DataNode会将其对外暴露的host:port提交给NameNode,后者会将该信息进一步下发给相关的其他DataNode或者client。
(摘自类注释)
计划花一个月左右的时间,通读一遍Hadoop 0.1.0的源码,尽量少写一些废话,多记录一些思考。
Random一下,就从分布式文件系统(DFS)开始吧。
DFS即分布式文件系统,集合多台机器存储在预定义位置上的一组文件作为存储构件,在此基础上实现一些分布式操作,从而对外抽象出一套基本文件读写API。